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unit. A transmission conduit is entitled to a content receiver. Rights related to the functional unit are received. The rights are corre- 
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ENTITLEMENTS OF OBJECTS AND RESOURCES 

This application claims the benefit of U.S. Provisional Application No. 
60/152,385 filed on September 3, 1999. 

BACKGROUND OF THE INVENTION 
This invention relates in general to secure access systems and, more 
specifically, to securing information within the secure access systems. 

Cable television (TV) providers distribute video streams to subscribers by 
way of conditional access (CA) systems. CA systems distribute video streams from a 
headend of the cable TV provider to a set top box associated with a subscriber. The 
headend includes hardware that receives the video streams and distributes them to the set 
top boxes within the CA system. Select set top boxes are allowed to decode certain video 
streams according to entitlement information sent by the cable TV provider to the set top 
box. 

Video program;; are distributed in either digital form or analog form to the 
set top boxes. There are around one hundred and twenty analog carrier channels in most 
cable television systems. The carrier channels either carry an analog video stream or 
carry multiple digital video streams. The analog video feed is modulated on a carrier and 
occupies the whole carrier channel for the one analog video feed. To maximize 
bandwidth, about eight to fourteen digital video streams may be statistically multiplexed 
on the same carrier channel. The separate digital video streams are separated by packet 
identification (PID) information such that the individual content streams can be removed 
according to their unique PID information. 

Video streams are broadcast to all set top boxes, but only a subset of those 
boxes is given access to specific video streams. For example, only those that have 
ordered a pay per view boxing match are allowed to view it even though every set top box 
may receive the match in encrypted form. Once a user orders the pay per view program, 
an entitlement message is broadcast in encrypted form to all set top boxes. Only the 
particular set top box the entitlement message is intended for can decrypt it. Inside the 
decrypted entitlement message is a key that will decrypt the pay per view program. With 
that key, the set top box decrypts the pay per view program as it is received in real-time 
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as either an analog or digital video stream. Accordingly, only whole video streams are 
entitled during download. 

Some systems, that do not provide conditional access, integrate personal 
computing with a TV for displaying programs. For example, products such as WebTV™ 
5 integrate web browsing and e-mail programs with a TV. In these systems, a personal 
computer (PC) is housed near the TV. The PC is connected to an Internet service 
provider (ISP) that provides the content for the web browsing and e-mail programs. 
These systems provide content without checking entitlements as is required in conditional 
access systems. 

10 

SUMMARY OF THE INVENTION . 
The invention relates to securing information in a secure access system. In 
one embodiment a method secures information in a conditional access system to authorize 
a functional unit. The functional unit has requirements related to the functional unit. A 
15 transmission conduit is entitled to a content receiver. Rights related to the functional unit 
arc received. The rights are correlated with the requirements. The rights are checked 
against the requirements to provide authorization of the functional unit. 

Reference to the remaining portions of the specification, including the 
drawings and claims, will realize other features and advantages of the present invention. 
20 Further features and advantages of the present invention, as well as the structure and 

operation of various embodiments of the present invention, are described in detail below 
with respect to the accompanying drawings. In the drawings, like reference numbers 
indicate identical or functionally similar elements. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 Fig. 1 is a block diagram showing one embodiment of a content delivery 

system; 

Fig. 2 is a block diagram illustrating an embodiment of a set top box 
interfaced to its environment; 

Fig. 3 is a block diagram depicting an embodiment of an object message; 
30 Fig. 4 is a block diagram showing an embodiment of a "rights" message; 

Fig. 5 is a block diagram showing an embodiment of a "requirements" 

message; 
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Fig. 6 is a block diagram showing the relationship between different 

objects in a set top box; 

Fig. 7 is a block diagram illustrating an embodiment of interaction 

between functional units; 
5 Fig. 8 is a flow diagram showing an embodiment of a process for 

distributing functional units; 

Fig. 9 is a flow diagram depicting an embodiment of a process for 

receiving functional units and authorizing them; 

Fig. 10 is a flow diagram illustrating an embodiment of a process for 
1 0 authenticating and authorizing a software object; 

Fig. 1 1 is a flow diagram illustrating an embodiment of a process for 
authenticating and authorizing a running software object; and 

Fig. 12 is a flow diagram illustrating another embodiment of a process for 
authenticating and authorizing a running software object. 

15 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
The present invention validates that functional units, such as software, are 
authorized for use within a television' (TV) set top box. Objects and resources are two 
examples of functional units. After the functional unit is installed in the set top box, 
20 authorization and/or authentication checks are performed when checkpoints are 

encountered. Checkpoints are triggered, for example, when the functional units in the set 

top box interact with each other. 

In the Figures, similar components and/or features may have the same 
reference label. Further, various components of the same type may be distinguished by 
25 following the reference label by a dash and a second label that distinguishes among the 
similar components. If only the first reference label is used in the specification, the 
description is applicable to any one of the similar components having the same first 
reference label irrespective of the second reference label. 

Referring first to Fig. 1, a block diagram of one embodiment of a content 
30 delivery system .100 is shown. The delivery system 100 selectively provides content to a 
number of users based upon certain conditions being satisfied. Included in the system 
100 are a headend 104, number of set top boxes 108, local programming receiver 1 12, 
satellite dish 116, and the Internet 120. 
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The headend 104 receives content and distributes that content to users. 
Content can include video, audio, interactive video, software, firmware, and/or data. This 
content is received from a variety of sources that could include the satellite dish 116, the 
local programming receiver 1 12, a microwave receiver, a packet switched network, the 
5 Internet 120, etc. Each set top box 108 has a unique address that allows sending 

entitlement information to an individual set top box 108. In this way, one set top box 
108-1 might be entitled to some particular content while another 108-2 might not. 
Equipment within the headend 104 regulates the subset of set top boxes 108 are entitled 
to some particular content. 

1 0 The content is generally distributed in digital form through an analog 

carrier channel that contains multiple content streams. All the content streams are 
multiplexed together into a digital stream that is modulated upon the analog carrier 
channel. The separate content streams are tracked by packet identification (PED) 
information such that the individual content streams can be removed according to their 

1 5 unique PED information. There are around one hundred and twenty analog carrier 

channels in this embodiment of the system 100. Other embodiments could distribute the 
content with transport mechanisms that include satellite dishes, microwave antennas, RF 
transmitters, packet switched networks, cellular data modems, carrier current, phone 
lines, and/or the Internet. 

20 Referring next to Fig. 2, a block diagram of an embodiment of a display 

system 200 is shown: This embodiment provides multiple levels of object and resource 
security through a variety of security mechanisms. Included in the display system 200 are 
a set top box 108, network 208, printer 212, TV display 216, and wireless input device 
218. These items cooperate in such a way that the user can enjoy content conditionally 

25 distributed by a content provider. The content can include video, audio, software, 

firmware, interactive TV, data, text, and/or other information. In this embodiment, the 
content provider is a cable TV provider or multiple system operator (MSO). 

The network 208 serves as the conduit for information traveling between 
the set top box 108 and the headend 104 of the cable TV provider. In this embodiment, 

30 the network has one hundred and twenty analog channels and a bi-directional control data 
channel. Generally, the analog channels* carry content and the control data, channel 
carries control and entitlement information. Each analog carrier channel has a number of 
digital channels multiplexed into one data stream where the digital channels are 
distinguished by packet identifiers (PBDs). The bi-directional control channel is an out- 
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of-band channel that broadcasts data to the set top boxes 108 at one frequency and 
receives data from the boxes 108 at another frequency. Return data may be queued to 
decrease overloading during peak use periods using a store and forward methodology 
well known in the art. Other embodiments could use a cable modem, digital subscriber 
5 line (DSL), cellular data, satellite links, microwave links, or carrier current techniques for 
both control information and content where the content is formatted as packet switched 
data. 

The printer 212 is an optional accessory some users may purchase and add 
to their display system 200. When using the set top box 108 for personal computer tasks, 
10 the printer 212 allows printing data such as email, web pages, billing information, etc. As 
will be explained further below, the ability to use a peripheral such as a printer is 
regulated by an authorization check. Using this regulation feature, printers 212 
compatible with the set top box 108 do not work unless proper authorization is obtained 
to enable that printer 212 for that set top box 108. 
1 5 The TV display 216 presents the user with audio, text and/or video 

corresponding to the content. The display 216 typically receives an analog video signal 
that is modulated on a carrier corresponding to channel three, channel four or a composite 
channel. The set top box 108 produces a NTSC signal, for example, modulated to the 
appropriate channel. Other embodiments could use a video monitor or digital display 
20 instead of a television display 216. Use of a digital display would alleviate the need for 
an analog conversion by the set top box 108 because digital displays, such as liquid 
crystal displays, use digital information to formulate the displayed picture. 

The wireless input device 218 allows interaction between the user and the 
set top box 108. This device 218 could be a remote control, mouse, keyboard, game 
25 controller, pen tablet or other input mechanism. An infrared transceiver on the input 
device 218 communicates with a similar transceiver on the set top box 108 to allow 
wireless communication. In other embodiments, RF link or wired link could be used 
instead of the infrared transceiver. 

The set top box 108 has component parts that perform authentication and 
30 authorization of objects and resources. Obj ects are any collection of digital information 
such as software, drivers, firmware, data, video, or audio. Resources are anything needed 
by an object to operate as intended such as another object or a physical device. Included 
in the set top box 108 are a controller 220, memory 228, a printer port 232, a network port 
. 236, an access control processor 240, a display interface 244, and an infrared (JR.) port 

5 
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248. These blocks communicate with each other over a bus 230 where each block has a 
different address to uniquely identify it on the bus 230. Typically, the set top box 108 is a 
separate device, but could be integrated with the TV display 216, a computer, an 
information appliance, or personal video recorder (PVR). 
5 The controller 220 manages operation of the set top box 108 using a 

trusted or secure operating system. Such functions as digital object decryption and 
decompression are performed in the controller 220 as well as functions such as switching 
TV channels for the user and presenting menus to the user. Included in the controller are 
a processor, an encryption engine, local memory, and other items common in computing 
10 systems. 

In other embodiments, the controller 220 could also contain an adjunct 
secure microprocessor for purposes of key protection or cryptographic processing. This 
may be appropriate in some systems where a high level of security is desired. 

The set top box 108 includes a block of memory 228. This memory 228 is 

1 5 solid state memory that could include RAM, ROM, flash, and other types of volatile and 
non-volatile memory. Objects and resources are stored in memory for running at a later 
time. During execution, programs are loaded into and executed within the memory 228, 
and also, use the memory 228 for scratchpad space. Keys, serial numbers and 
authorizations can be stored in non-volatile flash memory. 

20 This embodiment includes a printer port 232 for. interfacing to an optional 

printer 212. The printer port 232 resource is not available to programs unless authorized. 
As explained further below, each object must have authorization to use a resource such as 
the printer port 232. Data is sent from the printer port 232 to the printer 212 in a serial or 
parallel fashion by way of a wired or wireless transport mechanism. 

25 Stated generally, a checkpoint is a point in time or a step of processing 

where the authentication and/or authorization status of a functional unit is confirmed. A 
checkpoint is encountered when printing is requested. The checkpoint authorizes and 
authenticates the object requesting the printing. Checkpoints are places in one object 
where authentication and/or authorization are run on another object (e.g., an operating 

30 system checks authentication and authorization of an application that is running). Ideally, 
checkpoints are performed when the purpose of the object becomes manifest. In the case 
of a printer port 232, its purpose becomes manifest when it is used to print something. 
Accordingly, a checkpoint is triggered to check the object using the printer port 232 

6 

BNSDOCID:<WO 0119074A1 1 > 



WO 01/19074 PCT/US00/24097 

resource when anything is printed. Typically, the checkpoint for printing would be in the 
operating system. 

The network port 23 6 allows bi-directional communication between the set 
top box 108 and the headend 104. Included in the network port 236 are a tuner and a 
5 demodulator that tune to analog carrier channels and demodulate an MPEG data stream to 
allow one-way delivery of content. Also included in the network port 236 is a control 
data transceiver or cable modem that allows for bi-directional communication of control 
data information and/or content. To distribute loading of the control data path to the 
headend 104 more evenly, a store and forward methodology may be used. 
! 0 Modulation of the digital video signal onto an analog signal compatible 

with the TV display 216 is performed by the display interface 244. As discussed above, 
the TV display 216 generally accepts signals modulated on channel three, channel four or 
a composite channel. For displays that accept a digital input, such as LCD displays, the 
display interface 244 performs any formatting required by the digital input. 
15 The IR port 248 communicates bi-directionally with a wireless input 

device 218. Included in the JR. port 248 is an IR transceiver that provides the wireless 
communication path with the input device 218. Other electronics in the IR port 248 
convert analog signals received by the transceiver to a corresponding digital signal and 
convert analog signals sent to the transceiver from a corresponding digital signal. The 
20 controller 220 processed the digital signals so that the user can control some of the 
functions within the set top box 108. 

The access control processor (ACP) 240 regulates security functions 
within the set top box 108. For example, the ACP 240 performs authentication and 
authorization either under the direction of the controller 220 or independent of the 
25 controller 220 as will become clear in the discussion below. To perform its tasks, the 
ACP 240 includes a processor, RAM and ROM that cooperate to execute software 
independent of the controller 220. The ACP 240 also includes a decryption engine and a 
hash function for deciphering content and calculating signatures. Checkpoints are 
embedded into the software run that trigger the ACP 240 to perform security checks. In 
30 this embodiment, the ACP 240 is implemented in hardware, but other embodiments could 
perform the functions of the ACP 240 in software. 

The ACP 240 can also shadow the operating system (OS) to assure proper 
functioning of the OS. By watching the launch of objects, the ACP 240 can monitor 
which application objects are running. If necessary, the ACP 240 can kill running 
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applications if a checkpoint detects an error or if authorization expires. Further, the ACP 
240 could monitor memory 228 to detect any application not authorized to be in memory 
228. Scratchpad memory size could also be monitored to detect applications hiding in 
scratchpad memory. Additionally, the ACP 240 could randomly execute checkpoints on 
5 the objects in memory to confirm their authorization and/or authenticity. Problems 

encountered by the ACP 240 are reported to either the OS or the headend 104. In these 
ways, the ACP 240 acts as a software security guard bot within the set top box 1 08 such 
that aberrant behavior is detected and reported. 

With reference to Figs. 3, an embodiment of an object message 300 is 

10 shown in block diagram form. Object messages 300 deliver functional units to the set top 
box 108 from the network 208 such that information may be sent to the set top boxes 108 
after they are fielded. Forming the object message 300 are an object header 304, an 
object 308 and requirements 312. This embodiment includes requirement information in 
the object message 300, however, other embodiments could use a separate "requirements" 

15 message to convey this information. Although not shown in Fig. 3, checksums or digital 
signatures are used to validate that the object message 300 is transported to the set top 
box 108 from the headend 104 without errors. 

The object header 304 includes attributes for the object message 300. 
Included in the object header 304 are a header length, an object length, a functional unit 

20 identifier, a software version, and a domain identifier. The header and object lengths 
respectively indicate the lengths of the object header 304 and'the object 308. For 
authentication purposes, among other reasons, the functional unit identifier provides a 
unique code that allows attributing a "rights" message to the object message 300. The 
software version indicates the revision number of the object. Different cable TV 

25 providers are assigned domain identifiers such that all of the set top boxes 108, which 
might receive an object 308, can screen for objects 308 associated with their domain. 

The object 308 includes content the system 100 is designed to deliver to 
set top boxes 108. Upon download of the object 308, it is authenticated and authorized to 
verify the source of the object message 300 and availability of the object 308 to the 

30 receiving set top box 108. Several types of content or information can be embedded in an 
object, such as executable programs, firmware upgrades, run-time programs (e.g., Java® 
or ActiveX®), programming schedules, billing information, video, audio, and/or data. 
The object 308 can be used immediately after authentication and authorization or at a 
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later time. Additionally, authorization can be programmed to expire after a certain 
amount of time or can be rechecked periodically as the object 308 is used. 

The requirements data structure 312 allows the content provider to limit 
access of the object 308 to predetermined subset of all the set top boxes 108. Each 
5 functional unit identifier is mapped to one or more rights. Rights are transported in 

"rights" messages to enable- operation of a functional unit that is mapped to those rights in 
the requirements data structure 312. 

Referring next to Fig. 4, an embodiment of a "rights" message 400 is 
shown in block diagram form. The rights message 400 conveys rights to use a functional 
10 unit. The functional unit could be an object or a resource. Typically, there is one rights 
message 400 for each set top box 108, which specifies any rights for all functional units. 
Requirements associated with the objects and resources are checked against the rights to 
determine if interaction with another the object or resource is authorized. The rights 
message 400 allows remotely adding new rights to a functional unit associated with the 
15 set top box 108. Although not shown, the rights message 400 typically includes a digital 
signature to verify the integrity of the message 400 during transport. In some 
embodiments, a checksum could be used instead of a digital signature. 

The rights header 404 includes attributes for the rights message 400. 
Included in the rights header 404 are a header length, a rights data structure length, a 
20 functional unit identifier, and a domain identifier. The header length and the rights data 
structure length respectively indicate the lengths of the rights header 404 and the rights 
data structure 408. For authentication purposes, the functional unit identifier provides a 
unique code that allows attributing the rights message 400 to a particular functional unit. 

Rights are conveyed to the functional units using the information in the 
25 rights data structure 408. A given functional unit may have rights to use several other 
functional units. These rights are contained in the rights data structure 408. The 
functional unit identifier in the rights header 404 is used to attribute the rights to a 
particular functional unit. The functional unit may be already in the set top box 108 or 
may be downloaded at some later time. 
30 Referring next to Fig. 5, an embodiment of a "requirements" message 500 

is shown in block diagram form. The requirements message 500 is used for resources 
already resident in the set top box 108. Included in the requirements message 500 are a 
requirements header 504 and a requirements data structure 508. The requirements 
. message 500 is similar to the object message 300 except that there is no embedded object 
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308 as it is already located in the set top box 108. Although not shown, the requirements 
message 500 typically includes a digital signature to verify the integrity of the message 
500 during transport. ■ 

The requirements header 504 includes attributes for the requirements 
5 message 500. Included in the requirements header 304 are a header length, a 

requirements data structure length, and a domain identifier. The header and requirements 
data structure lengths respectively indicate the lengths of the requirements header 504 and 
the requirements data structure 308. Different cable TV providers are assigned domain 
identifiers such that all of the set top boxes 108, which might receive an object 308, can 
10 screen for objects 308 associated with their domain. 

The requirements data structure 508 allows the content provider to limit 
access of a resource to predetermined subset of all set top boxes 108. Each functional 
unit identifier is mapped to one or more requirements by the requirements data structure 
508. Rights are transported in the rights message 400 to enable operation of a functional 
15 unit so long as the rights in the rights message 400 satisfy the requirements in the 
requirements data structure 508 for that functional unit. 

The object message 300 is uniquely coupled with the associated 
requirements message 500 by a signature over both messages 300, 500. Even though 
transported separately, the common signature assures the pair of messages 300, 500 are 
20 not modified during transport. 

With reference to Fig. 6, some of the functional units of a set top box 108 
are shown. Functional units toward the bottom of Fig. 6 are superordinate to the 
functional units near the top of Fig. 6. That is to say, functional units toward the top of 
Fig. 6 are subordinate to those lower in the figure. Superordinate functional units are 
25 responsible for imposing checkpoints on subordinate functional units. For example, the 
hardware 604 imposes checkpoints upon the BIOS 608, OS 612 and so on up the 
subordination hierarchy. The BIOS 608 imposes checkpoints on the OS 612, but not 
upon the hardware 604. Functional units in the same ordination stratum can impose a 
checkpoint on another functional unit in that stratum when they interact. For example, an 
30 application 616 can require execution of a checkpoint on a driver 618. 

Superordinate functional units are designed to initiate execution of the 
checkpoints in conjunction with the ACP 240 and subordinate objects are designed to 
have checkpoints imposed upon them. For example, the BIOS 608 requires execution of 
a checkpoint upon the OS 612 during the boot process, during execution and/or 

10 
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10 



periodically while running. A driver object 618 is subject to checkpoints when installed 
or exercised during normal operation. Data file objects 622 are subject to checkpoints 
whenever the data in the file is accessed. An HTML object 628 is reviewed as part of a 
checkpoint whenever the HTML object 628 is interpreted by a browser application 616. 

Referring next to Fig. 7, interaction between functional units is shown in 
block diagram form. The .functional units associated with the set top box 108 include a 
set top box resource 704, a printer driver object 708, an e-mail object 712, and a printer 
port resource 716. During the normal interaction of these functional units, checkpoints 
arc encountered that trigger authorization checks. The sole table correlates rights and 
requirements to each functional unit in Fig. 7. The functional unit identifier serves to 
correlate the object messages 300 with the rights messages 400. 



Functional Unit ID 


Functional Unit 


Requirements 


Rights 


t>04 


Set Top Box 


NA 


E-mail, Printer Driver, etc. 


612 1 


E-mail 


Yes 


Printer Driver 


60S 


Printer Driver 


Yes 


Printer Port 


6U 


Printer Port 


Yes 


None 



The set top box resource 704 is superordinate to the email object 712. 
1 5 When the email object 712 is loaded, a checkpoint in the object 712 checks for proper 
rights. The proper rights are defined by the requirements 720-2 of the email object 712 
itself. If the e-mail right 716-1 meets the standards of the e-mail object requirements 720- 
2, the e-mail object 712 continues execution past the checkpoint. The ACP 240 actually 
performs the authentication after the e-mail right 716-1 and e-mail object requirements 
20 720-2 are respectively loaded by their associated functional units 704, 712. 

After the user receives the set top box 704, the user can add an optional 
printer 212. In this embodiment, the ability to print is an added feature that is not 
included in all set top boxes 704. If the printer 212 is a purchase sanctioned by the 
content provider, printer driver rights 716-2, 716-4 and a printer port right 716-3 are sent 
25 in rights messages 400 to the set top box 704 from the headend 1 04. 

Some embodiments could provide rights to a subset of the functional units 
capable of using the printer port 720-3. For example, the e-mail object 712 could be 
given the printer driver right 716-4, but the set top box resource 704 would not receive 
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the printer driver right 716-2. In this way, only the email object 716-2 could use the 
printer port 720-3 and the other objects could not. 

Hooking the printer to the to the printer port can trigger display of a 
message on the TV 216 that asks for a secret code included with the printer 212. After 
5 the user enters the secret code, a request for the rights messages 400 that enable the 
printer is made to the headend 104. Once the headend receives and verifies the secret 
code, an enabling set of rights messages 400 are sent encrypted in a key based upon the 
secret code. In this embodiment, the printer driver object 708 is factory loaded, but other 
embodiments could load this object 708 when needed using an object message 300. 
10 While the e-mail object 712 is running, the user may try to print an e-mail 

message. Several checkpoints authenticate the proper rights 716 are present before 
printing. The e-mail object 712 calls the printer driver 708 with the information requiring 
printing. A checkpoint in the printer driver 708 stops processing until the authorization of 
the e-mail object 712 is checked. A printer driver right 716-4, downloaded when the 
15 printer was purchased, is loaded into the ACP 240 along with the printer driver 

requirements 720-1 for authentication. Presuming authentication is successful, the printer 
driver object 708 formats the print information for the printer 212 and passes it to the 
printer port resource 714. 

The printer port resource 714 is the hardware port that interfaces to a cable 
20 connected to the printer 212. Once information is sent to the printer port resource 714 a 
checkpoint pauses the processes to check that the printer driver object 708 has proper 
authorization. The requirements 720-3 and rights 716-3 are loaded into the ACP 240 for 
authentication. Once the use by the printer driver object 708 is authenticated, the 
remainder of the print job is spooled to the printer port resource 714 for printing. 
25 In some embodiments, the rights 716 of one functional unit can be 

inherited by another functional unit. The right 716 could be conveyed to other objects 
308 that might use that functional unit. For example, the right 716 to use the printer port 
232 could initially be associated with the e-mail object 712 alone, where this right 716 is 
conveyed to e-mail object 712 when the user purchased a printer 212. At a later time, the 
30 headend 104 could authorize inheritance of that right 712 to all other functional units or 
subset of the functional units that might use the printer port 232. In this way, additional 
functional units could use the print feature. 

With reference to Fig. 8, a flow diagram of an embodiment of a process for 
loading functional units is illustrated. This embodiment allows factory loading or field 
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loading of functional units. The process begins in step 804 where the functional units are 
designed. Functional units can be objects and/or resources. The resources include 
hardware such as the set top box 108 and the hardware components inside the set top box 
108. During step 804, the various requirements for the functional units are denned. 

A determination is made in step 808 as to whether the functional unit is 
being installed in the factory or in the field. As those skilled in the art appreciate, 
resources that are physical devices are typically installed at the factory. Electronically 
storable objects can generally be installed in the factory or the field, however, certain 
objects are installed in the factory such as portions of the operating system 612. 

If the particular functional unit being installed is factory loaded, 
processing continues to step 812 where the functional units are installed into the set top 
box enclosure. Typically, the physically devices and most of the objects are factory 
installed such that the set top box is functional before shipment to the user. Certain 
objects 308, however, are loaded into the set top box 108 after fielding it. 

For field loaded objects, processing goes from step 808 to step 820 where 
the objects are distributed to content providers. The distribution process includes 
electronically sending the object 308 by some type of data link such as a packet switched 
network. The content provider embeds the objects 308 in object messages 300 and 
broadcasts the objects 308 to set top boxes 108 over an entitled channel in step 824. The 
entitlement process for the channel includes sending keys to the entitled set top boxes 
• such that they can decode the data stream on the channel. In step 828, the rights 716 for 
innning the objects are determined by the content provider. The rights messages 400 are 
distributed in step 832. Only a subset of the set top boxes 108 who are broadcast the 
object 308 are typically allowed to decode the corresponding rights message 400. In this 
embodiment, the object message 300 is sent before the rights message 400, but other 
embodiments could reverse the order of sending the messages 300, 400. 

Referring next to Fig. 9, an embodiment of a process for receiving an 
object 308 is shown in flow diagram form. This embodiment receives the object and 
rights messages 300, 400 before authenticating their use. In steps 904 and 908, the object 
and rights messages 300, 400 are received from the cable TV provider by way of an 
entitled channel. Entitlement of a channel involves encryption of the channel for one or 
more set top boxes 108 using symmetric or asymmetric encryption techniques. 
Signatures can also be used to verify the source of the messages 300, 400 is authentic and 



13 



WO 01/19074 



PCT/US00/24097 



verify their authorization for use on the set top box 1 08 . Other embodiments, could 
receive the rights message 400 before the object message 300. 

Once successfully the messages 300, 400 are received and decrypted, they 
are correlated to each other using the functional unit identifiers in step 916. In step 920, 
5 the requirements 720 embedded in the object 308 are checked against the rights 716 in the 
rights message 400. This check of rights 716 against requirements 720 allows a 
determination as to whether the object 308 is authorized in step 924. If the object 308 is 
not authorized, an error is reported back to the headend 104 and the object 308 is 
discarded in steps 928 and 932. Alternatively, use of the object 308 is allowed in step 
10 936 if the rights 716 satisfy the requirements 720. In this way, the object 308 is sent to 
the set lop box 108 and checked for authorization. 

Although the forgoing embodiment downloads an object 308 and 
authorizes it, other embodiments could authorize resources already in the set top box 108 
w ithout requiring download of the resource. Under this scenario, the rights message 400 
15 is checked against the requirements already stored in the set top box 108. 

With reference to Fig. 10, a flow diagram illustrating an embodiment of a 
process for authenticating and authorizing a software object 308 is shown. The process 
begins in step 1 004 where the software object 308 is read into the controller 220 from 
memory 22 S. A signature associated with the software object 308 is checked in step 1008 
20 to determine if the object 308 is authentic. As mentioned above, the signature could be 
generated over both the object message 300 and requirements message 500 to provide 
authentication of both messages 300, 500 with the single signature. The software object 
308 and requirements message 500 are loaded into the ACP 240 to calculate the 
signature. The calculated signature is checked against the original signature sent from the 
25 headend 1 04 to check authentication. 

If it is determined that the software object fails the authentication as 
determined in step 1012, processing continues to steps 1016 and 1020. In step 1016, an 
error is reported to the headend 104. This may happen immediately where a bi- 
directional control data channel is available or may happen at a later time where a store- 
30 and-forward methodology is used. Objects 308 that fail the authenticity test are corrupt 
and are discarded in step 1020. A message may or may not be presented to the user after 
failure of authentication. 

In step 1032, a check of authorization is performed for a resource to use an 
object 308. The rights 716 of the set top box 108 are checked against the requirements 
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720 for the resource. It is noted, the resource could be the same object 308 being 
executed such that a checkpoint causes an authorization check of the very object 308 that 
includes the checkpoint. The ACP 240 is involved in this authorization process to 
securely check rights against requirements. 

5 A determination is made in step 1 036 as to whether the interaction 

between object 308 and resource is authorized. If the use is not authorized, the error is 
reported to the user and/or headend 108 in step 1040. For example, a message could 
appear on the screen to notify the user that the printer port is unavailable and that the 
content provider should be contacted to enable this feature. If the authorization check is 

1 0 successful, the object 308 is allowed to begin execution in step 1 024. 

In another embodiment, authorization could be checked before 
authentication rather than the other way around. Authorization is typically a quicker 
check than authentication and a negative result from an authorization check could avoid 
unnecessarily checking authentication. 

! 5 in yet another embodiment, the resource accessed by the object 308 could 

also encounter a checkpoint that requires authentication. For example, the printer port 
resource 232 may have a requirement 720 that needs satisfaction by a corresponding right 
716. The ACP 240 is once again used to perform this authentication. In this way, various 
functional units have checkpoints applied to them to check authentication and/or 

20 authorization. 

With reference to Fig. 1 1 , a flow diagram illustrating an embodiment of a 
process for authenticating the running of a software object and for authorizing that 
software object 308 is shown. The process begins in step 1 104 where the software object 
308 is read into the controller 220 from memory 228. The software object 308 is checked 
25 in step 1 1 08 to determine if the object 308 is authentic and authorized. 

If it is determined that the software object fails either the authorization or 
authentication as determined in step 1 1 12, processing continues to steps 1 1 1 6 and 1 120. 
In step 1 1 1 6, an error is reported to the headend 114. This may happen immediately 
where a bi-directional control data channel is. available or may happen at a later time 
30 where a store-and^forward methodology is used. Objects 308 that fail the authentication 
or authorization test are corrupt and are discarded in step 1 120. . A message may or may 
not be presented to the user after a failure. 

Presuming it is determined that the software object 308 is authorized and 
. authentic in step 1 112, execution of the software object 308 is begun in step 1 124. 
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During execution, a checkpoint is encountered in the software object 308 that requires 
authorization in step 1 128. Checkpoints are typically added to. the software object 308 in 
places where the purpose of that object 308 becomes manifest. For example, a printer 
driver would have a checkpoint before the driver is used to access the printer port 232. 
5 The checkpoint could require authorization and/or authentication of the object containing 
the checkpoint and/or another resource. 

In step 1 132, a check of resource authorization is performed for an object 
308. The resource rights 716 of the set top box 1 18 are checked against the resource 
requirements 720 for the object. It is noted, the resource needed could be the same object 

10 308 being executed such that the checkpoint causes an authorization check of the very 
object 308 that includes the checkpoint. The ACP 240 is involved in this authorization 
process to securely check rights against requirements. 

A determination is made in step 1 136 as to whether the interaction 
between object 308 and the necessary resource is authorized. If the use is not authorized, 

1 5 the error is reported to the user and/or headend 1 1 8 in step 1 140. For example, a message 
could appear on the screen to notify the user that the printer port is unavailable and that 
the content provider should be contacted to enable this feature. If the authorization check 
is successful, the object 308 is allowed to use the resource in step 1 144. 

There are many permutations of checking authorization and authentication 

20 of software objects and authorization of the resources the software objects access. Only 
some of those permutations are described herein, but it is to be understood the invention 
includes these permutations. The above embodiment checks authorization and 
authentication of the software object before execution and checks authorization of the 
resource at a checkpoint during execution. Other embodiments, however, could perform 

25 the authorization of the resource before execution of the software object and the 

checkpoint could perform authorization and authentication of the software object again. 

With reference to Fig. 12, a flow diagram illustrating another embodiment 
of a process for authenticating the running of a software object and for authorizing that 
software object 308 is shown. The process begins in step 1204 where the software object 

30 308 is read into the controller 220 from memory 228. . A signature associated with the 
" software object 308 is checked in step 1208 to determine if the object 308 is authentic. 
As mentioned above, the signature could be generated over both the object message 300 
and requirements rights message 400 500 to provide authentication of both messages 300, 
400 500 with the single signature. The software object 308 and rights requirements 
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message 400 500 are loaded into the ACP 240 to calculate the signature. The calculated 
signature is checked against the original signature sent from the headend 124. 

If it is determined that the software object fails the authorization as 
determined in step 1212, processing continues to steps 1216 and 1220. In step 1216, an 
5 error is reported to the headend 124. This may happen immediately where a bi- 
directional control data channel is available or may happen at a later time where a store- 
and-forward methodology is used. Objects 308 that fail the authenticity test are corrupt 
and are discarded in step 1220. A message may or may not be presented to the user after 
failure of authorization. 

1Q Presuming it is determined that the software object 308 is authentic in step 

1212, execution of the software object 308 is begun in step 1224. During execution, a 
checkpoint is encountered in the software object 308 that requires authorization in step 
1228. Checkpoints are typically added to the software object 308 in places where the 
purpose of that object 308 becomes manifest. For example, a printer driver would have a 

15 checkpoint before the driver is used to access the printer port 232. The checkpoint could 
require authorization and/or authentication of the object containing the checkpoint and/or 
another resource. 

In step 1232, a check of authorization is performed for an object 308 to use 
a resource. The resource rights 716 of the set top box 128 are checked against the 
20 requirements 720 for the object 308. It is noted, the resource could be the same object 
308 being executed such that the checkpoint causes an authorization check of the very 
object 308 that includes the checkpoint. The ACP 240 is involved in this authorization 
process to securely check rights against requirements. 

A determination is made in step 1 236 as to whether the interaction 
25 between object 308 and resource is authorized. If the use is not authorized, the error is 
reported to the user and/or headend 128 in step 1240. For example, a message could 
appear on the screen to notify the user that the printer port is unavailable and that the 
content provider should be contacted to enable this feature. If the authorization check is 
successful, the object 308 is allowed to use the resource in step 1244. 
30 in light of the above description, a number of advantages of the present 

invention are readily apparent. Functional units such as object or resources can be 
controlled in a computer system at any time a checkpoint is encountered by checking 
authentication and/or authorization. This ability allows conditional access and 
verification of functional units at multiple times during their use in a system. As those 
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skilled in the art can appreciate, these techniques reduce the threat of viruses and other 
unwanted modifications or substitutions of functional units. 

A number of variations and modifications of the invention can also be 
used. Some embodiments could use the ACP to perform authentication and authorization 
checks while others could perform these checks with similar software algorithms. 

Although the invention is described with reference to specific 
embodiments thereof, the embodiments are merely illustrative, and not limiting, of the 
invention, the scope of which is to be determined solely by the appended claims. 
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WHAT T£ CLAIMED IS: 

1 1 . A method for securing information in a conditional access system, 

2 the method comprising: 

3 providing a functional unit; 

4 providing requirements related to the functional unit; 

5 entitling a transmission conduit to a content receiver; 

6 receiving rights related to the functional unit; 

7 correlating the rights with the requirements; and 

8 checking the rights against the requirements. 

1 2. The method for securing information in the conditional access 

2 system of claim 1 , wherein the functional unit includes at least one of an object and a 

3 resource. 

1 3. The method for securing information in the conditional access 

2 system of claim 2, wherein the object comprises at least one of software, drivers, 

3 firmware, data, video, and audio. 

1 4. The method for securing information in the conditional access 

2 ■ system of claim 2, wherein the resource comprises at least one of an object and a physical 

3 device. 

1 5. The method for securing information in the conditional access 

2 system of claim 1 , further comprising authenticating a source of the functional unit. 

1 6. The method for securing information in the conditional access 

2 system of claim 1, further comprising authorizing use of the functional unit if the right 

3 satisfies the requirement. 

1 7. The method for securing information in the conditional access 

2 system of claim 1 , wherein the entitling the transmission conduit comprises decrypting 

3 information passing through the transmission conduit. 

1 8. A method for securing information in a conditional access system, 

2 the method comprising: 

3 entitling a transmission conduit to a content receiver; 
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4 sending a functional unit to the content receiver; 

5 determining requirements for the functional unit; and 

6 sending the requirements through the transmission conduit, wherein the 

7 requirements are related to the functional unit. 

1 9. The method for securing information in the conditional access 

2 system of claim 8, comprising determining rights associated with the content receiver. 

1 10. The method for securing information in the conditional access 

2 system of claim 8, allowing inheritance of a right from a first functional unit to a second 

3 functional unit. 

1 11. The method for securing information in the conditional access 

2 system of claim 8, further comprising sending rights to the functional unit. 

1 12. The method for securing information in the conditional access 

2 system of claim 11, further comprising: 

3 correlating the rights to the functional unit; and 

4 checking the rights against the requirements. 

1 13. The method for securing information in the conditional access 

2 system of claim 11, wherein the entitling a transmission conduit comprises encrypting 

3 information passing to the transmission conduit. 

1 14. The method for securing information in the conditional access 

2 system of claim 8, further comprising authenticating the functional unit. 

1 15. A content receiver for a conditional access system, comprising: 

2 a body; 

3 an encrypted channel from a content provider to the body; 

4 a functional unit within the body; 

5 requirements related to the functional unit; and 

6 rights related to the functional unit, wherein the rights are checked against 

7 the requirements to authorize use of the functional unit. 

1 16. The content receiver for the conditional access system of claim 15, 

2 wherein the functional unit includes at least one of an object and a resource. 
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1 17. The content receiver for the conditional access system of claim 15, 

2 further comprising a second functional unit, wherein the rights of the functional unit are 

3 inherited by the second functional unit. 

1 18. The content receiver for the conditional access system of claim 15, 

2 wherein a source of the functional unit is authenticated. 

1 19. A method for authorizing interaction between functional units in a 

2 computing system, the method comprising: 

3 providing a first functional unit associated with a requirement; 

4 providing a second functional unit associated with a right; 

5 initiating interaction between the first and second functional units; 

6 checking the right against the requirement in response to the initiation of 

7 interaction between the first and second functional units; and 

8 authorizing use of the first functional unit by the second functional unit. 

1 20. The method for authorizing interaction between functional units in 

2 the computing system of claim 19, further comprising authenticating a source of at least 

3 one of the first functional unit and the second functional unit. 

1 21. The method for authorizing interaction between functional units in 

2 the computing system of claim 19, further comprising entitling a transmission conduit for 

3 transporting at least one of the first functional unit and the second functional unit. 
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